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Abstract 

A  new  format  for  standardizing  common  view  time  transfer  data,  recommended  by  the  Consul¬ 
tative  Committee  for  the  Definition  of  the  Second,  is  being  implemented  in  receivers  commonly  used 
for  contributing  data  for  the  generation  of  International  Atomic  Time.  We  discuss  three  aspects  of 
this  new  format  that  potentially  improve  GPS  common-view  time  transfer:  (1)  the  standard  specifies 
the  method  for  treating  short  term  data,  (2)  it  presents  data  in  consistent  formats  including  needed 
terms  not  previously  available,  and  (3)  the  standard  includes  a  header  of  parameters  important  for 
the  GPS  common-view  process.  In  coordination  with  the  release  of  firmware  conforming  to  this 
new  format  the  Bureau  International  des  Poids  et  Mesures  will  release  future  international  track 
schedules  consistent  with  the  new  standard. 


INTRODUCTION 

A  new  format  for  standardizing  common  view  time  transfer  data,  recommended  by  the  Consul¬ 
tative  Committee  for  the  Definition  of  the  Second  (CCDS),  is  being  implemented  in  receivers 
commonly  used  for  contributing  data  for  the  generation  of  International  Atomic  Time  (TAI). 
The  primaiy  means  of  remote  dock  comparison  for  generating  TAI  is  common-view  GPS  time 
transfer!1!  .  The  global  accuracy  for  this  type  of  time  transfer  is  currently  less  than  10  ns!2! 
.  Understanding  the  sources  of  inaccuracy,  the  BIPM  initiated  an  effort  to  standardize  data- 
taking  methods  used  in  receivers  and  data  transfer  methods  used  for  reporting  to  the  BIPM. 
By  combining  this  effort  with  the  use  of  good  coordinates,  precise  GPS  satellite  ephemerides, 
and  measured  local  ionospheric  delays,  we  hope  to  increase  the  accuracy  for  common-view 
time  transfer!3!  . 

One  of  the  major  motivations  for  standardization  is  the  implementation  of  Selective  Availability 
(SA)  in  GPS  satellites.  With  SA,  GPS  timing  is  degraded  as  a  way  of  limiting  the  navigation 
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Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 
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accuracy  available  to  the  standard  positioning  service  (SPS)  user.  This  follows  since  navigation 
in  GPS  is  accomplished  using  measurements  of  time  as  received  from  satellites.  If  common-view 
time  transfer  is  performed  strictly,  that  is,  with  measurements  taken  on  identical  seconds,  and 
with  receivers  which  process  the  signals  and  the  data  identically,  then  the  GPS  satellite  clocks 
cancel  completely.  SA  makes  this  need  for  strict  common-view  even  more  important.  We 
include  in  this  paper  some  direct  satellite  data  with  SA  and  predict  the  effects  on  common-view 
time  transfer  due  to  differences  in  receivers.  Thus,  a  standard  can  improve  time  transfer  by 
allowing  common-view  time  transfer  to  be  done  with  different  receivers  and  still  cancel  the 
effects  of  the  satellite  clock. 

The  new  format  has  potential  to  improve  GPS  common-view'  time  transfer  due  to  a  number 
of  elements:  (1)  the  standard  specifies  the  method  for  treating  short  term  data,  (2)  it  presents 
data  in  consistent  formats  including  needed  terms  not  previously  available,  and  (3)  includes  a 
header  of  parameters  important  for  the  GPS  common-view  process.  Essential  to  common-view 
time  transfer  is  that  stations  track  satellites  according  to  a  common  schedule.  In  coordination 
with  the  release  of  firmware  conforming  to  this  new  format  the  Bureau  International  des  Poids 
et  Mesures  (BIPM)  will  release  future  international  track  schedules  consistent  with  the  new 
standard.  In  this  paper  we  summarize  information  about  the  short-term  data  processing,  the 
header  and  the  data  format.  When  developing  the  standard  for  a  receiver,  one  should  obtain 
all  the  detailed  information  as  reported  in  the  Technical  Directives!4!  . 

SHORT  TERM  DATA  PROCESSING 

Data  processing  is  performed  as  follows: 

1.  Pseudo-range  data  are  recorded  for  times  corresponding  to  successive  dates  at  intervals  of 
Is.  The  date  of  the  first  pseudo-range  data  is  the  nominal  starting  time  of  the  track.  It  is 
referenced  to  UTC  and  appears  in  the  data  file  under  the  acronyms  MJD  and  STTIME. 

2.  Least-squares  quadratic  fits  are  applied  on  successive  and  nonoverlapping  sets  of  15 
pseudo-range  measurements  taken  every  second.  The  quadratic  fit  results  are  estimated 
at  the  date  corresponding  to  the  midpoint  of  each  set. 

3.  Corrections  are  applied  to  the  results  of  (2)  to  obtain  estimates  of  the  local  reference 
minus  the  Satellite  Vehicle  (SV)  clock  (REFSV)  and  of  the  local  reference  minus  GPS 
time  (REFGPS)  for  each  15  second  interval. 

4.  The  nominal  track  length  corresponds  to  the  recording  of  780  short-term  measurements. 
The  number  of  successive  and  nonoverlapping  data  sets  treated  according  to  (2)  and  (3) 
is  then  equal  to  52.  For  full  tracks,  the  track  length  TRKL  will  thus  equal  780  s. 

5.  At  the  end  of  the  track,  least-squares  linear  fits  are  performed  to  obtain  and  store  the 
midpoint  value  and  slope  for  both  REFSV  and  REFGPS.  Since  these  two  are  related 
deterministically  by  nearly  a  straight  line  they  will  have  the  same  rms  deviation  around 
the  fit,  which  is  also  stored  as  DSG.  In  addition,  least-squares  linear  regression  gives  the 
midpoint  and  slope  of  the  ionospheric  and  tropospheric  model  values,  and  the  ionospheric 
measurements  if  they  exist. 
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THE  EFFECTS  OF  SA 


We  investigate  the  effects  of  SA  by  taking  measurements  every  15  s  of  GPS  -  UTC(NIST) 
tracking  different  satellites  from  horizon  to  horizon.  We  took  data  sequentially  from  three 
different  satellites  on  two  consecutive  days,  November  21-22,  1994.  The  satellites  had  pseudo¬ 
random  code  numbers  (PRN’s)  20,  22,  and  25.  Figures  1-3  show  the  data  from  the  three 
satellites,  and  Figures  4-6  show  the  time  deviation  TDEV  of  the  three,  respectively. 

The  new  standard  will  cancel  all  the  clock  dither  when  used  for  common-view'  GPS  time 
transfer,  provided  that  each  of  the  two  receivers  involved  track  the  same  satellites  over  the 
same  time  periods.  If  there  is  a  difference  of  15  s  in  the  tracking,  for  example  if  one  receiver 
tracks  15  s  less  than  the  other,  then  the  clock  dither  of  SA  will  corrupt  the  common-view  time 
transfer.  We  can  estimate  this  by  looking  at  the  expected  dispersion  in  time  at  due  to  SA  at  15 
s.  The  rms  of  the  three  TDEV  values  for  r  =  15  s  is  11  ns.  From  the  TDEV  plots  we  see  that 
the  slope  on  the  log-log  plots  starts  consistent  with  a  model  of  t°  from  15-30  s.  If  we  assume 
a  model  of  flicker  phase  modulation  (PM)  for  r  =  15  s  this  implies  an  expected  time  dispersion 
of  13  nsf5!  .  Over  a  13  min  track  there  are  52  estimates  of  REFGPS  and  REFSV  each  from  a 
quadratic  fit  over  15  s  of  data.  Let  us  consider  the  case  w'here  one  track  is  a  full-length  track 
and  the  matching  track  in  another  receiver  is  15  s  short.  If  we  can  assume  that  the  effects  of 
one  15  s  point  average  down  in  the  linear  fit  as  the  square  root  of  the  total  number  of  points, 
then  we  can  expect  the  effect  on  the  common-view  time  transfer  to  be 


13ns 

\/52 


=  1.8 


ns. 


(1) 


Thus  SA  could  add  approximately  2  ns  to  a  common-view  uncertainty  budget  with  only  a 
mis-match  of  15  s  from  exact  common-view.  With  a  goal  of  1  ns  we  see  the  reason  why  a 
standard  for  data  taking  can  help  common-view  time  transfer. 

Many  users  receive  GPS  time  directly  from  the  satellites  without  using  the  common-view 
method  to  compare  with  another  lab.  From  considering  the  TDEV  of  SA,  we  can  design  a 
filter  that  averages  SA  optimally,  to  allow  users  to  obtain  the  best  possible  restitution  of  GPS 
timeM  .  From  the  three  TDEV  analyses  we  see  a  bump  rising  from  1  min  and  dropping  at  16 
min.  This  effect  could  be  due  in  part  to  a  periodic  behavior  with  a  period  of  approximately  16 
minl7l,8  .  Averaging  can  improve  the  GPS  restitution  if  the  TDEV  values  drop  with  increasing 
< insert  4>.  Yet  there  is  no  indication  in  these  data  that  the  TDEV  values  drop  significantly 
beyond  16  min.  This  may  be  due  to  effects  at  the  beginning  and  end  of  the  tracks  when  the 
elevation  is  low.  This  suggests  limitations  on  the  potential  for  filtering  SA.  Yet  our  data  were 
taken  using  a  single  channel  receiver.  A  multi-channel  receiver  could  improve  on  filtering.  It 
may  be  that  the  combination  of  SA  signals  still  drop  in  TDEV,  allowing  improvement  from 
averaging. 


THE  DATA  FORMAT 

The  data  format  consists  of: 
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1.  a  file  header  with  detailed  information  on  the  GPS  equipment, 

2.  a  line  header  with  the  acronyms  of  the  reported  quantities, 

3.  (3)  a  unit  header  with  the  units  used  for  the  reported  quantities, 

4.  (4)  a  series  of  data  lines,  one  line  corresponding  to  one  GPS  track.  The  GPS  tracks 
are  ordered  in  chronological  order,  the  track  reported  in  line  n  occurring  after  the  track 
reported  in  line  (n-1).  Each  line  of  the  data  file  is  limited  to  128  columns  and  is  terminated 
by  a  carriage-return  and  a  line  feed.  The  format  for  one  line  of  data  can  be  represented 
as  follows: 


No  measured  ionospheric  delays  available 

oooooooooooooooooooooooooooooooooooooooooooooo 

00000000011 1111 1111222222222233333333334444444 
1234567890123456789012345678901234567890123456 
PRN*CL**MJD**STTIME*TRKL*ELV*AZTH***REFSV***** 
*************RRnu]!iss**s** .  ldg* .  ldg**** .  ins***** 

*12* 12* 12345* 12 12 12* 1234* 123* 1234*+ 1234567890* 

0000000000000000000000000000000000000000000000000000011 
4445555555555666666666677777777778888888888999999999900 
7890123456789012345678901234567890123456789012345678901 
*SRSV*****REFGPS****SRGPS**DSG*IOE*MDTR*SMDT*MDID*SMDI* 
. lps/s***** . Ins**** . lps/s* . ins***** . Ins . lps/ s . Ins . lps/s 
+12345*+1234567890*+12345*1234*123*1234*+123*1234*+123* 

111111111111111111111111111 
00000000 11111111 11222222222 
234567890123456789012345678 
CK 
** 

12optionalcommentsoptionalc 


Measured  ionospheric  delays  available 

0000000000000000000000000000000000000000000000 
00000000011 1111 1111222222222233333333334444444 
1234567890123456789012345678901234567890123456 
PRN*CL**MJD**STTIME*TRKL*ELV*AZTH***REFSV***** 
*************h.hminss**s**  •  ldg* .  ldg**** ,  ins***** 
*12* 12* 12345*121212* 1234* 123* 1234*+1234567890* 
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0000000000000000000000000000000000000000000000000000011 
4445555555555666666666677777777778888888888999999999900 
7890123456789012345678901234567890123456789012345678901 
*SRSV*****REFGPS****SRGPS**DSG*IOE*MDTR*SMDT*MDIO*SMDI* 
. lps/s***** . ins**** . lps/s* . ins***** . Ins . lps/s . Ins , lps/s 
+ 12345*+ 1234567890*+12345* 1234* 123* 1234*+ 123* 1234*+ 123* 

111111111111111111111111111 
000000001111111111222222222 
2345678901234567890 12345678 
MSrO*SHSI*ISG*CK 
. Ins . lps/s, Ins** 

1234*+123* 123* 12opt comments 


The  following  is  an  example  of  what  the  data  looks  like,  using  fictitious  data. 


Example  (fictitious  data) 

GGTTS  GPS  DATA  FORMAT  VERSION  =01 
REV  DATE  =  1993-05-28 
RCVR  =  AOA  TTR7A  12405  1987  14 
CH  =  15 

IMS  =  99999  or  IMS  =  AIR  NIMS  003  1992 

LAB  =  XXXX 

X  =  +4327301.23  m 

Y  =  +568003.02  m 

Z  =  +4636534.56  m 

FRAME  =  ITRF88 

COMMENTS  =  NO  COMMENTS 

INT  DLY  =  85.5  ns 

CAB  DLY  =  232.0  ns 

REF  DLY  =  10.3  ns 

REF  =  10077 

CKSUM  -  C3  or  CKSUM  =  49 
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No  measured  ionospheric  delays  available 


PRN 

CL  MJD 

STTIME 

TRKL 

ELV 

AZTH 

REFSV 

SRSV 

REFGPS 

SR GPS 

DSG 

I0E 

MDTR  SMDT  MDIO  SMDI  i 

:k 

hhmm.q.q 

s 

,idg 

•  ldg 

,  Ins 

. lps/s 

.  Ins 

. lps/s 

.  Ins 

.  Ins. 

lps/s 

3 

8D  48877 

20400 

780 

251 

3560 

-3658990 

+  100 

+4520 

+100 

21 

221 

64 

+90 

-27 

BBhello 

18 

02  48877 

35000 

780 

650 

910 

+56987262 

-5602 

+5921 

-5602 

350 

123 

102 

+61 

281 

+26  52 

15 

11  48878 

110215 

765 

425 

2700 

+45893 

+4892 

+4269 

+4890 

306 

55 

54 

-32 

+  15 

A9 

15 

88  48878 

120000 

780 

531 

2850 

+45992 

+4745 

+4290 

+4745 

400 

55 

57 

-29 

+16  18receiv.  out  of  operation 


Measured  ionospheric  delays  available 


PRN 

CL  MJD  STTIME  TRKL  ELV 

AZTH 

REFSV 

SRSV 

REFGPS 

SRGPS 

DSG 

IQE 

MDTR  SMDT  MDIO  SMDI  MS 10 

SMSI 

ISG  CK 

hhmmss  s  -ldg 

•ldg 

.  Ins 

. lps/s 

.  ins 

.  lps/s 

.  Ins 

. Ins . lps/s . Ins . lps/s . Ins . lps/s . Ins 

3 

8D  48877  20400  780  251 

3560 

-3658990 

+  100 

+4520 

+100 

21 

221 

64 

+90 

-27 

480  -37  18  F4hello 

18 

02  48877  35000  780  650 

910 

+56987262 

-5602 

+5921 

-5602 

350 

123 

102 

+61 

281 

+26  9999  9999  999  89no  meas  ion 

15 

11  48878  110215  765  425 

2700 

+45893 

+4892 

+4269 

+4890 

306 

55 

54 

-32 

+  15 

599  +16  33  29 

15 

88  48878  120000  780  531 

2850 

+45992 

+4745 

+4290 

+4745 

400 

55 

57 

-29 

+16  601  +17  29  OOrec  out 
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The  definitions  of  the  acronyms  used  in  the  data  format  follow.  Note  that  a  *  stands  for  a 
space,  ASCII  value  20  (hexadecimal).  Text  to  be  written  in  the  data  file  is  indicated  by  ’  ’. 

Pile  header 

Line  1:  ’GGTTS*GPS*DATA*FORMAT*VERSION*  =  *01,  title  to  be  written. 

Line  2:  REV*DATE*  =  *’  YYYY’-’MM’-’DD,  revision  date  of  the  header  data,  changed  when  1 
parameter  given  in  the  header  is  changed.  YYYY-MM-DD  for  year,  month  and  day. 

Line  3:  ’RCVR*  =  *’  MAKER’*’TYPE’*’SERIAL  NUMBER’*’YEAR’*\  maker  acronym,  type, 
serial  number,  first  year  of  operation,  and  eventually  software  number  of  the  GPS  time 
receiver. 

Line  4:  ’CH*  =  *’  CHANNEL  NUMBER,  number  of  the  channel  used  to  produce  the  data  included 
in  the  file,  C-H  =  01  for  a  one-channel  receiver. 

Line  5:  TMS*  =  *’  MAKER’*TYPE’*’SERIAL  NUMBER’*’YEAR’*\  maker  acronym,  type,  serial 
number,  first  year  of  operation,  and  eventually  software  number  of  the  Ionospheric 
Measurement  System.  IMS  =  99999  if  none. 

Line  6:  ’LAB*  =  *’  LABORATORY,  acronym  of  the  laboratory  where  observations  are  performed. 

Line  7:  ’X*  =  *’  X  COORDINATE  ’*m’,  X  coordinate  of  the  GPS  antenna,  in  m  and  given  with 
at  least  2  decimals. 

Line  8:  ’Y*  =  *’  Y  COORDINATE  ’*m\  Y  coordinate  of  the  GPS  antenna,  in  m  and  given  with 
at  least  2  decimals. 

Line  9:  ’Z*  =  *’  Z  COORDINATE  ’*m’,  Z  coordinate  of  the  GPS  antenna,  in  m  and  given  with 
at  least  2  decimals. 

Line  10:  ’FRAME*  =  *’  FRAME,  designation  of  the  reference  frame  of  the  GPS  antenna  coordi¬ 
nates. 

Line  11:  ’COMMENTS *  =  *’  COMMENTS,  Any  comments  about  the  coordinates,  for  example  the 
method  of  determination  or  the  estimated  uncertainty. 

Line  12:  TNT*DLY*  =  *’  INTERNAL  DELAY  ’*ns\  internal  delay  entered  in  the  GPS  time  receiver, 
in  ns  and  given  with  1  decimal. 

Line  13:  ’CAB*DLY*  =  *’  CABLE  DELAY  ’*ns\  delay  coming  from  the  cable  length  from  the 
GPS  antenna  to  the  main  unit,  entered  in  the  GPS  time  receiver,  in  ns  and  given  with  1 
decimal. 

Line  14:  ’REF*DLY*  =  *’  REFERENCE  DELAY  ’*ns’,  delay  coming  from  the  cable  length  from 
the  reference  output  to  the  main  unit,  entered  in  the  GPS  time  receiver,  in  ns  and  given 
with  1  decimal. 
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Line  15:  ’REF*  =  *’  REFERENCE,  identifier  of  the  time  reference  entered  in  the  GPS  time 
receiver.  For  laboratories  contributing  to  TAI  it  can  be  the  7-digit  code  of  a  clock  or  the 
5-digit  code  of  a  local  UTC,  as  attributed  by  the  BIPM. 

Line  16:  ’CKSUM*  =  *’  XX,  header  check-sum:  hexadecimal  representation  of  the  sum,  modulo 
256,  of  the  ASCII  values  of  the  characters  which  constitute  the  complete  header,  beginning 
with  the  first  letter  ’G’  of  ’GGTTS’  in  Line  1,  including  all  spaces  indicated  as  *  and 
corresponding  to  the  ASCII  value  20  (hexadecimal),  ending  with  the  space  after  ’  =  ’  of 
Line  16  just  preceding  the  actual  check  sum  value,  and  excluding  all  carriage  returns  or 
line  feeds. 

Line  17:  blank  line. 
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Acronyms 


The  following  are  the  detentions  of  the  acronyms 


PRN: 

CL: 

MJD: 

STTIME: 

TRKL: 

ELV: 

AZTH: 

REFSV: 

SRSV: 

REFGPS: 

SRGPS: 

DSG: 


IOE: 

MDTR: 

SMDT: 

MDIO: 

SMDI: 

MSIO: 

SMSI: 

ISG. 

CK: 


Satellite  vehicle  PRN  number. 

Common-view  hexadecimal  class  byte. 

Modified  Julian  Day. 

Date  of  the  start  time  of  the  track  in  hour,  min  and  second  referenced  to  UTC. 
Track  length,  780  for  full  tracks,  in  s. 

Satellite  elevation  at  the  date  corresponding  to  the  midpoint  of  the  track  in  0.1 
degree. 

Satellite  azimuth  at  the  date  corresponding  to  the  midpoint  of  the  track  in  0.1 
degree. 

Estimate  of  the  time  difference  of  local  reference  minus  SV  clock  at  the  middle 
of  track  from  the  linear  fit,  in  0.1  ns. 

Slope  of  the  linear  fit  for  REFSV  0.1  ps/s. 

Estimate  of  the  time  difference  of  local  reference  minus  GPS  time  at  the  middle 
of  the  track  from  the  linear  fit,  in  0.1  ns. 

Slope  of  the  linear  fit  for  REFGPS  0.1  ps/s. 

[Data  Sigma]  Root  mean  square  of  the  residuals  to  the  linear  fit  for  REFGPS 
in  0.1  ns. 

[Index  of  Ephemeris]  Three  digit  decimal  code  (0-255)  indicating  the  ephemeris 
used  for  the  computation. 

Modelled  tropospheric  delay  at  the  middle  of  the  track  from  the  linear  fit,  in  0.1 
ns. 

Slope  of  the  modelled  tropospheric  delay  resulting  from  the  linear  fit  in  0.1  ps/s. 
Modelled  ionospheric  delay  resulting  from  the  linear  in  0.1  ns. 

Slope  of  the  modelled  ionospheric  delay  resulting  from  the  linear  fit  in  0.1  ps/s. 
Measured  ionospheric  delay  resulting  from  the  linear  fit  in  0.1  ns. 

Slope  of  the  measured  ionospheric  delay  resulting  from  the  linear  in  0.1  ps/s. 
[Ionospheric  Sigma]  Root  mean  square  of  the  residuals  to  the  linear  fit  in  0.1  ns. 
Data  line  check-sum:  hexadecimal  representation  of  the  sum,  modulo  256,  of 
the  ASCII  values  of  the  characters  which  constitute  the  data  line,  from  column 
1  to  space  preceeding  the  check-sum.  (both  included).  There  can  be  optional 
comments  on  the  data  line  after  the  check  sum  out  to  the  128  character  line 
length.  These  characters  are  not  included  in  the  line  check-sum. 


CONCLUSIONS 

The  new'  GPS  data  format,  along  with  the  prescription  for  processing  short  term  data,  can  help 
improve  common-view  time  transfer.  Especially  with  the  implementation  of  SA,  common-view 
tracks  can  be  significantly  degraded  if  the  two  receivers  tracking  in  common  view  do  not  work 
identically.  The  new  standard  can  help  us  move  toward  a  goal  of  1  ns  time  transfer  accuracy 
across  intercontinental  distances  using  GPS  time  transfer  in  common-view. 
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QUESTIONS  AND  ANSWERS 


DAVID  ALLAN  (ALLAN’S  TIME):  I  would  like  to  just  highlight  the  importance  of  the 
paper  you  presented  on  this  new  standard.  Just  to  tell  everybody,  we  believe,  as  we  go  through 
the  theory  of  all  the  errors  in  common  view,  that  with  this  new  standard  that  an  accuracy  of 
one  ns  is  achievable.  To  date,  only  about  four  ns  has  been  documented  just  by  way  of  where 
we  are  versus  where  we  think  the  standard  can  take  us.  So  I  think  it’s  very  important  work  for 
the  operational  aspects,  for  clock  input  to  TAI  and  UTC.  So  thank  you  for  sharing  it  with  us. 

The  other  point  that  I  would  like  to  make  is  on  the  TDEV  plot,  that  it  is  not  a  necessary  and 
sufficient  condition  that  if  you  have  a  hump  in  the  data  that  it’s  due  to  a  periodic  event.  There 
are  at  least  two,  and  probably  more,  basic  processes  in  the  essay  spectrum,  and  if  one  looks 
at  longer-term  data,  in  fact,  this  is  confirmed;  and  there  is  not  necessarily  just  the  60-minute 
type  periodic  phenomena.  It’s  really  two  pretty  much  separate  parallel  processes;  and,  in  fact, 
period  modeling  is  not  the  best  model  that  one  would  want  to  use. 

I  simply  want  to  point  out  that  it’s  not  a  necessary  and  sufficient  condition,  given  a  hump,  that 
there  is  a  periodic  event. 

M.J.  VANMELLE  (ROCKWELL):  A  couple  of  things.  The  rubidium  is  on  20  and  not  on 
25.  So  it’s  hard  to  tell  between  rubidiums  and  cesiums  there. 

Also,  did  you  ever  do  the  experiment  on  the  satellites  that  don’t  have  SA  on  them,  like  number 
ten?  Do  you  get  that  same  two  ns  error  with  15  seconds  separation? 

MARC  A.  WEISS  (NIST):  No,  it’s  lower.  I’m  sorry,  at  15  seconds.  I’m  not  sure.  There 
should  be  very  short-term  —  -  I’m  not  sure  what  we  were  trying. 

HAROLD  CHADSEY  (USNO):  A  quick  question  for  you.  You  were  talking  about  the  fact 
that  when  you  do  the  common  view  that  everything  drops  out.  What  about  geometrical  effects? 
Also,  the  fact  that  speed  of  the  wave  is  not  constant  through  the  atmosphere,  and  you’ll  be 
effected  more  through  a  thick  atmosphere  than  through  a  small  atmosphere? 

MARC  A.  WEISS  (NIST):  What  I  said  that  the  effects  of  Selective  Availability  cancel 
completely  if  you  do  exact  common-  view  time  transfer  and  use  a  post-process  ephemeris.  Of 
course,  the  effects  of  ionosphere  and  troposphere  are  still  there,  Those  need  to  be  dealt  with. 
The  ionosphere,  by  measuring,  and  the  troposphere  can  be  helped  also  with  measurements. 
They  need  to  be  if  we’re  going  to  get  the  best  we  can. 

GERNOT  M.  WINKLER  (USNO):  I  think  the  time  has  come  to  start  a  little  controversy, 
because  we  are  all  too  peaceful  down  here.  You  have  somehow  attacked  obliquely  one  of  the 
tenants  of  my  gospel  which  I  have  been  preaching  for  10  years.  That  is  the  melting  pot  method 
can  average  out  by  having  a  sufficient  amount  of  data  —  -  it  can  average  out  the  effects  of 
Selective  Availability.  Your  comment  was  that  you  cannot  be  sure  that  biases  are  averaging 
out. 

I  want  to  remind  you  that  the  common  view  —  -  that’s  true;  I  mean,  the  common  view  cancels 
the  effect  of  Selective  Availability;  but  in  the  Selective  Availability,  the  satellites  themselves  are 
not  correlated;  and  the  noise,  which  is  superimposed,  is  strictly  bounded.  So  if  you  have  these 
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conditions  and  a  sufficient  amount  of  data  collection,  you  completely  suppress  the  individual 
noise.  It  just  depends  on  how  much  data  you  need.  And  it  turns  out  that  if  you  have  an 
eight-channel  receiver  and  you  average  about  six  hours,  that  you  cannot  distinguish  the  resulting 
time  transfer  data  from  what  we  obtain  with  the  keyed  receiver. 

The  great  advantage  of  a  melting-pot  method,  compared  to  the  common  view,  is  that  it  is  a 
robust  method.  You  obtain  perfection  just  commensurate  with  the  effort  that  you  have.  You 
have  internal  checks  on  the  result  which  you  have,  because  we  have  a  statistic  of  the  variations. 
In  a  case  of  the  common  view,  you  have  nothing.  We  know  that  in  practice  your  one  ns  or  two 
ns  accuracy  cannot  be  achieved.  The  question  is,  how  do  you  check  operation  in  an  automatic 
system?  How  do  you  check  that  you  really  can  rely  on  a  single  data  point  in  comparison  to 
the  melting  pot  where  you  always  have  lots  of  data?  Whatever  happens,  it  will  produce  an 
outlier  which  is  rejected. 

So,  I  wanted  to  bring  that  out  because  there  is  a  great  difference  in  the  basic  philosophy.  In 
the  common  view,  theoretically  you  have  a  superior  method;  but  in  practice,  I  maintain  there 
are  weaknesses;  and  do  you  lack  a  measure  of  performance  as  compared  to  the  melting-pot 
method  where  you  have  everything  you  need?  Do  you  have  really  a  robust  method  which 
protects  you  against  outliers  of  whatever  magnitude  in  fact? 

MARC  A.  WEISS  (NIST):  I  would  like  to  respond  to  that.  Thank  you.  Dr.  Winkler.  I 
know  for  years  now  we’ve  had  differences  on  this.  It’s  going  to  wake  people  up  a  little  bit.  One 
point  is  that  we  don’t  have  only  a  point  in  common  view.  We  can  do  pretty  much  everything 
with  common  view  that  you  do  with  a  melting  pot,  and  more.  That  with  the  melting  pot,  if 
you  have  a  eight-channel  receiver  at  two  locations,  then  why  not  take  the  eight  channels  of 
data  simultaneously  at  the  two  locations  and  cancel  all  the  effects  of  SA,  and  then  use  robust 
statistics  on  the  resulting  data  where  all  the  biases  have  been  cancelled,  and  all  that’s  left  is 
the  noise?  So  I  think  all  the  statistics  that  you  do  with  melting  pot  are  still  there  with  common 
view. 

The  other  thing  is  that  because  data  are  bounded  does  not  in  itself  imply  that  averaging  brings 
you  down  to  a  single  correct  number.  It  may,  in  fact  —  -  I  don’t  doubt  that  it  has  worked  on 
many  occasions;  but  simply  saying  that  they’re  bounded  does  not  —  -  there’s  no  reason  that  it 
should  average  down  correctly. 

GERNOT  M.  WINKLER  (USNO):  But  we  have  a  check,  because  you  look  at  the  distribution 
of  your  measurement  points.  On  that  you  simply  add  all  that  area,  which  we  have  to  do  to 
obtain  the  competence  of  that  area. 

MARC  A.  WEISS  (NIST):  I  don’t  agree  with  that.  You  can  have  all  the  data  averaging 
down  to  the  wrong  number.  I  understand  that  that  is  not  what  you’ve  found  by  doing  it.  But 
there’s  no  guarantee  that  that  always  will  happen. 

CLAUDINE  THOMAS  (BIPM):  Of  course,  I  will  have  some  words.  For  TAI,  we  have  46 
contributing  laboratories,  I  mean,  laboratories  keeping  local  UTC;  and  most  of  them  are  using 
GPS  now.  First  of  all,  all  of  these  laboratories,  except  maybe  USNO,  have  only  one  channel 
CA  code  receiver.  That  is  to  say,  except  for  USNO,  no  one  has  one  channel  receivers  which 
are  given  reliable  measurements.  So  obviously,  we  have  no  data  to  do  the  measurements  at 
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the  present  time.  Maybe  it  will  come,  but  that’s  not  the  case  for  the  moment.  That’s  the  first 
point. 

The  second  point  is  that  view  of  the  BIPM  for  the  computation  of  TAI  has  always  been  to  try 
to  reduce  errors  in  the  physical  phenomena  which  are  invoked;  for  instance,  for  the  ionospheric 
delay,  we  like  to  use  measured  ionospheric  delays  as  they  are  labelled.  For  the  position  of  the 
satellite,  we  like  to  use  precise  satellite  ephemerides.  For  the  antenna  coordinates,  huge  work 
was  done  some  years  ago  by  my  colleague.  Dr.  Lewandowski  (he  can  speak  about  that)  in 
which  he  found  accurate  positions  for  the  antennas.  So  we  have  always  tried  to  phase  all  our 
sources  and  trying  to  reuse  them.  That  was  our  viewpoint  and  that  is  what  we  did  until  now. 
That  was  the  way  we  worked. 

The  last  point,  of  course,  common-view  time  transfer  is  done,  it’s  computed.  To  find  time 
difference  between  two  local  UTCs,  we  have  a  range,  of  course,  for  a  long-distance  time  link, 
like  between  NIST  and  OP;  we  have  a  range  common  view  for,  let’s  say,  two  or  three  days.  So 
we  have  some  kind  of  average  of  course.  For  a  smaller  distance,  like  between  Paris  and  PTB, 
Germany,  we  have  a  range,  let’s  say,  of  less  than  one  day.  So  that  is  to  say  we  have  some  kind 
of  average  too. 

I  would  say  that  what  we  are  doing  at  the  present  time  is  the  best  we  can  do  with  the  data  we 
have. 

RICHARD  KEATING  (USNO):  You’ve  stated  that  with  common  view,  you’re  eliminating 
all  these  errors.  I  assume  that’s  because  of  symmetry.  But  that’s  a  theoretical  position.  When 
you  get  down  to  actual  practice,  reality  doesn’t  always  follow  theory.  I  just  have  to  ask  you, 
how  confident  are  you  that  you  have  no  biases  in  common  view?  Can  you  really  say  that  you 
can  average  and  you  are  not  getting  any  biases? 

MARC  A.  WEISS  (NIST):  Well  what  would  a  bias  be  due  to? 

RICHARD  KEATING  (USNO):  Well,  for  example,  I’ll  give  you  an  example.  I  have  seen 
estimates  of  precise  ephemeris  accuracies.  They’ve  ranged  from  anything  from  one  meter  to  20 
meters.  There  is  a  real  possibility  there  that  your  precise  ephemerides  may  not  be  as  accurate 
and  may  contain  real  biases. 

MARC  A.  WEISS  (NIST):  I  think  that’s  a  good  point  in  fact.  Biases  have  to  be  due  — - 
if  you  look  at  the  common-view  process,  you  have  the  satellite  and  then  you  have  the  ground 
stations  on  the  earth;  and  then  you  have  the  atmosphere.  So  if  you  measure  it  exactly  at 
the  same  time  —  -  the  only  thing  I’m  claiming  that  cancels  exactly  is  Selective  Availability.  In 
fact,  the  only  thing  I  know  for  sure  that  cancels  is  clock  dither.  The  ephemeris  cancels  to  the 
extent  that  an  error  is  perpendicular  to  the  line  between  the  satellites.  If  there  is  an  error  in 
the  satellite  position,  it  will  add  an  error  to  common-view  time  transfer.  And  in  fact,  with 
precise  ephemerides,  prior  to  having  the  laser  reflector,  we  had  no  way  of  knowing  if  they  were 
accurate.  They  were  simply  consistent. 

Errors  can  also  come  in  the  atmosphere  due  to  ionosphere  and  due  to  troposphere,  due  to 
multi-path  at  the  stations,  and  due  to  coordinate  errors.  So  all  of  those  things  can  add  errors. 
It’s  going  to  be  true  whether  you’re  using  melting  pot  or  common  view  or  anything.  Those  are 
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all  in  GPS.  Whenever  you  do  GPS,  you’re  concerned  about  ephemeris,  ionosphere,  troposphere, 
and  multi-path,  and  coordinates. 

I  think  a  point  that  1  would  really  like  to  stress  about  that  —  -  and  1  think  your  point  is  well 
made  —  -  is  that  it’s  the  difference  between  accuracy  and  stability;  that  you  can  have  numbers 
that  agree  perfectly,  that  are  extremely  well  consistent  and  are  consistently  wrong.  For  example, 
if  you  took  a  commercial  cesium  clock  —  -  and  this  is  the  difference  between  a  commercial 
cesium  and  a  laboratory  primaiy  standard.  If  you  have  a  commercial  cesium  and  it’s  produced 
by  a  manufacturing  technique,  and  there’s  a  millimeter  error  in  the  end-to-end  phase  shift  in 
the  cavity,  all  the  clocks  will  have  that;  and  they’ll  all  be  off  in  frequency  because  of  that,  in 
exactly  the  same  way;  and  all  the  other  effects  will  average  down  and  you’ll  end  up  with  a  bias 
that  does  not  average. 

That’s  an  example  of  the  difference  between  stability  and  accuracy.  I  think  we  need  to  be  very 
careful  when  we  use  the  word  “accuracy.”  We’re  not  talking  about  something  that  yon  can 
average;  we’re  talking  about  something  that  you  have  to  prove, 

GERNOT  M.  WINKLER  (USNO):  You’re  example  is  making  my  point.  How  do  you  find 
out  that  all  of  these  cesiums  have  a  bias? 

MARC  A.  WEISS  (NIST):  You  evaluate  them. 

GERNOT  M.  WINKLER  (USNO):  You  evaluate  them  and  you  look  at  the  statistical 
distribution  of  what  there  frequencies  are;  and  you  compare  them  with  a  standard.  You  found 
out  how  it  is. 

MARC  A.  WEISS  (NIST):  But  you  don’t  compare  with  another  standard.  You  evaluate 
them  independently;  you  measure  the  effects  through  something  that’s  completely  independent. 

CLAUDINE  THOMAS  (BIPM):  There’s  a  very  big  question  of  the  difference  between 
stability,  precision  and  accuracy  of  course.  There  were  some  fundamental  and  formal  papers 
about  that  at  the  BIPM.  We  consider  that  an  accuracy  is  characterized  by  an  uncertainty  given 
as  a  one  sigma  value  which  was  from  the  quadratic  sum  of  the  different  uncertainties  which  are 
estimated  from  the  different  sources  of  errors  which  appear  within  common-view  time  transfer. 
I  have  already  at  the  BIPM  tried  to  do  that,  and  I  think  that  we  can  estimate  an  uncertainty  of 
about  10  ns,  it’s  eight  to  ten  ns,  one  sigma  for  long-distant  GPS  common  view,  using  precise 
satellite  ephemerides  from  the  IGS,  and  ionospheric  measurements  and  with  the  hypotheses 
that  the  receivers  themselves  are  correctly  calibrated,  which  may  not  be  the  case;  and  which 
could  add,  of  course,  a  bias.  So  let’s  say  eight  to  ten  ns,  one  sigma  as  the  accuracy  of  GPS 
common  views. 
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